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Description 

METHOD OF UTILIZING VARIABLE 
DATA FIELDS WITH A PAGE 
DESCRIPTION LANGUAGE 

Cross Reference to Related Applications 

[0001] This application is a continuation of U.S. Patent Applica- 
tion Serial No. 10/090,529, which is a divisional of U.S. 
Patent Application Serial No. 09/299,502, and issued as 
U.S. Patent No. 6,381,028; which is a continuation of U.S. 
Patent Application Serial No. 08/896,899, filed July 18, 
1997, and issued as U.S. Patent No. 5,937,153; which is a 
continuation-in-part of U.S. Patent Application Serial No. 
08/373,582, filed January 18, 1995, and issued as U.S. 

Patent No. 5,729,665. 
Background of Invention 

[0002] The present invention relates to the high-speed printing 
industry, and more particularly, to a method for printing 
variable data using a page description language in a high- 



speed printing environment. 

® 

[0003] Application programs, such as Adobe Illustrator , typically 
include a program which generates a specification of a 
screen or page's contents in a page description language. 
The specification, or page description code, provides in- 
structions as to how to generate the image in a printer. 
The page description code is transferred from the appli- 
cation program to a printer, where it is executed to gen- 
erate a bit map of the page. The most commonly used 

® 

page description language is PostScript , which is a ma- 
chine independent language produced by Adobe Systems, 
Inc. 

[0004] An application program page typically contains a number 
of data areas with either graphic or alphanumeric data. 
The PostScript language includes commands that define 
or build "graphics states" for each of the data areas on the 
page. These graphics states are sets of default attributes 
such as angle, scale factor, type-font, location, etc., which 
define how data is to appear on the page. Often, multiple 
graphics states are defined for a single page, with the dif- 
ferent graphic states corresponding to different data areas 
on the page. Examples of commands that are used in 
PostScript to build a graphics state are: 20 rotate, / 



Times-Roman findfont, 14 scalefont, and setfont. In addi- 
tion to commands which build graphics states, PostScript 
specifications also include the graphic or alphanumeric 
data which is displayed in the data areas, as well as a print 
command such as "SHOW", which causes a bit map to be 
generated for the data. 
[0005] | n the past, page description languages, including 

PostScript, have only been used to print static data pages, 
because page description languages lack the functionality 
required for variable data printing. In variable data print- 
ing, each page shares a common background, and the 
displayed data in at least one data field changes for each 
page. Up until now, it has not been possible to print pages 
of variable data with page description languages such as 
PostScript, because the page description languages are 
unable to save page backgrounds and graphics states 
from a page specification, and are thus unable reuse the 
same background and graphics states when printing sub- 
sequent pages. Thus, with page description languages 
such as PostScript, whether the entire page is changed, or 
only a single item of data on the page is changed, a new 
page description language specification is generated to 
print each separate page. 



[0006] For example, if thousands of copies of a mass mailing ad- 
vertisement were to be printed, each copy being identical 
except for the recipient's name and address, it would be 
necessary to generate a new PostScript specification 
defining the page background, and the graphics states for 
the name and address fields, for each new name and ad- 
dress that is printed. Hence, to print 50 advertisements, it 
would be necessary to generate 50 PostScript specifica- 
tions which each define virtually the same image. 

[0007] | n general, PostScript specifications are very complex and 
require extensive processing to generate and execute. 
Thus, generating a new PostScript specification each time 
a page of variable data is printed consumes an immense 
amount of processing time. In high-speed printing sys- 
tems, it is typically the processing time, not the printer 
hardware, which determines the speed at which pages can 
be printed. Therefore, the processing required to repeti- 
tively redefine the same background and graphics states 
for each page of variable data significantly slows the en- 
tire printing system. 

[0008] Due to the amount of processing time consumed in re- 
defining the page template and graphics states for each 
new page of data that is printed, as well as the resultant 



effect on printing speed, it is desirable to have a method 
for processing variable data wherein once defined, the 
template and graphics states for a page can be stored and 
reused for printing subsequent pages. Further, it is desir- 
able to have a method for printing variable data which is 
compatible with existing printing systems and page de- 
scription languages, such as PostScript, and which is ca- 
pable of processing variable data in a high-speed indus- 
trial printing system. 
Summary of Invention 

[0009] it is an object of the present invention to provide a 

method for utilizing variable data with a page description 
language, which enables the template and graphics states 
for a page of variable data to be defined and stored; and 
which enables the stored graphics states to be associated 
with multiple items of variable data from a database or 
merge file; so that once stored, the graphics states can be 
repeatedly applied to the items of variable data to print 
multiple pages of variable data or multiple variable data 
bitmaps. Further, it is an object of the present invention 
to provide such a method which is compatible with exist- 
ing page description languages, and which can be used in 
a high-speed industrial printing system. 



[0010] The method of the present invention is implemented by 
means of a control task which executes in conjunction 
with a page description code interpretive program, such 
as a PostScript program, to identify variable data areas in 
the page description code specification, and reserve the 
graphics states for the variable data areas as they are de- 
fined by the specification. After the interpreter program 
has executed, a merge task is initiated. The merge task 
associates items of variable data from a data file with the 
reserved graphics states, generates a bit map for each 
variable data area, merges the bit maps with the page 
template, and outputs a complete bit map for the page. 
Accordingly, in the method of the present invention, bit 
maps for multiple pages of variable data are generated 
from a single page description language specification. 

[001 1] The present invention assumes the generation of a page 
specification in PostScript, or another similar page de- 
scription language, by the application program, and the 
transfer of this specification to a printer. According to the 
present invention, a control task activates and monitors 
the PostScript interpreter program in the printer. As the 
interpreter executes, it defines graphics states for the 
data areas on the page. The PostScript attributes for a 



graphics state are stored in a stack as they are defined, so 
that at any given point in the code, the stack represents 
all of the PostScript attributes for the current graphics 
state. 

[0012] when the control task identifies a print command in the 
code, the control task interrupts the interpreter to deter- 
mine whether the data to be printed is variable data. If the 
data is variable, the current graphics state, consisting of 
the attributes then existing in the stack and job specific 
attributes which are defined in a job file, is linked to the 
data area and reserved in an internal database. Further, 
character bit maps are generated in accordance with the 
graphics state, and linked to and reserved with the graph- 
ics state. After the graphics state and character bit maps 
have been reserved, the PostScript interpreter is resumed 
at the line of code following the print command. 

[0013] The interpreter continues executing until either the con- 
trol task detects another print command, or the last line 
of code is reached. If a second print command is detected, 
the interpreter is interrupted again and the above steps 
repeated, to reserve the stack contents and job attributes 
for the second data area, and to generate and store a sec- 
ond set of character bit maps. The control task continues 



in this manner monitoring and interrupting the interpreter 
program, until all of the variable data areas on the page 
have been detected, and graphics states and possibly 
character bit maps for the variable data areas have been 
reserved in the database. 

[0014] As the PostScript interpreter executes, a bit map of the 

non-variable background graphics and text, otherwise re- 
ferred to as a "template", is generated for the page. At the 
last code command, which in PostScript is typically "SHOW- 
PAGE," the control task terminates the PostScript inter- 
preter, and reserves the template in the database. 

[0015] The merge task is then initiated to print variable data 

pages using the reserved page template, graphics states 
and character bit maps. The merge task begins by retriev- 
ing a merge file containing the variable data to be printed. 
After retrieving the merge file, the task identifies the cor- 
rect template for the current page, and the names of the 
graphics states related to that template, from data in the 
merge file. Then, using the name of the first graphics 
state reserved for the template, the merge task retrieves 
the graphics state from the database and the character bit 
maps linked to that state. The merge task then retrieves 
data corresponding to that graphics state from the appro- 



priate field in the merge file, and generates a bit map of 
the data in accordance with the graphics state and char- 
acter bit maps. The merge task then merges the data bit 
map into the template. After the bit map has been gener- 
ated and merged, the merge task identifies retrieves an- 
other graphics state for the template and repeats the pro- 
cess. If there are no more graphics states which corre- 
spond to variable data areas on the page, the merge task 
outputs the finished bit map for the page. 
[0016] After the first page of data has been printed, the merge 
task retrieves a "clean" template from the database, and 
again identifies the graphics states for the page. The 
merge task then retrieves the next record of variable data 
from the database, and generates variable data bit maps 
for each of the fields in the record, in accordance with the 
reserved graphics states and character bit maps which 
correspond to each of the fields. The merge task contin- 
ues in this manner, identifying variable data areas and 
generating bit maps for the variable data in the merge file, 
until a page has been printed for each variable data record 
in the file. 

[0017] The method of the present invention is advantageous in 
that once the graphics states and template have been de- 



fined for a variable data page, they can be reused to print 
multiple pages of variable data with only a minimal 
amount of additional processing. 

[0018] Accordingly, it is an object of the present invention to 
provide a method for printing variable data with a page 
description language; a method which increases the speed 
at which variable data pages can be printed; a method 
which enables the printing attributes for a page to be 
saved and used for printing multiple pages of data; and a 
method which is compatible with existing page descrip- 
tion languages and printing systems. 

[0019] other objects and advantages of the present invention will 
be apparent from the following description, the accompa- 
nying drawings and the appended claims. 
Brief Description of Drawings 

[0020] pig. 1 is a data flow diagram illustrating the preferred em- 
bodiment of the method of the present invention; 
[0021] pig. 2 is an example of a variable data page generated in 

accordance with the method of the present invention. 
Detailed Description 

[0022] The present invention provides a computer-implemented 
method for reserving graphics states, which enables a 



page description language to be used for variable data 
printing. In accordance with the present invention, graph- 
ics states describing variable data areas are generated by 
a page interpreter program and reserved in an internal 
database. The graphics states are later accessed from the 
database and used for printing variable data pages. The 
method of the present invention can be employed with a 
conventional page description language, such as 
PostScript, to enable variable data pages to be printed 
with a minimum amount of processing. 
[0023] As shown in Fig. 1, an image containing text and/or 
graphics data is created at a workstation 10, using a 

® 

graphics application program such as Adobe Illustrator . 
As the image is created, the application program displays 
the image on the workstation screen. When the image is 
complete and ready to be printed as a page, the applica- 
tion program generates a specification of the image in 
PostScript in a conventional manner. 
[0024] After the PostScript file 11 is generated, it is transferred 
from the workstation 10 to a printer generally designated 
as 12. In the printer 12, a PostScript interpreter 14 is exe- 
cuted to generate a pagemap of the image. In the method 
of the present invention, a control task operates in the 



printer 12 to initiate the PostScript interpreter program 14 
and a merge task 16. The control task is initiated upon 
power-on of the printer 12, and controls and coordinates 
the variable data printing. 

[0025] As the PostScript interpreter 14 executes, it defines the 

PostScript graphics state attributes for the page. These at- 
tributes can include the size, font, position, orientation, 
and location in which the graphic or text data is to appear 
on the page. The specifics of the attributes which are 
available in PostScript to define how data is to appear on a 
page would be well-known to one skilled in the art. 
Therefore, further description of these PostScript at- 
tributes is not provided. 

[0026] However, one of the PostScript attributes, namely the re- 
gion, has been expanded in the present invention to allow 
for variable data printing. In the method of the present in- 
vention, the region attribute is used to define the bound- 
aries or extent to which a variable data graphics state will 
be allowed to effect a page. The graphics state extent is 
an invisible boundary which acts as a clippath for the 
page, to prevent variable data for a particular graphics 
state from extending outside the intended boundaries of 
the graphics state. The region of the graphics state extent 



is defined without altering PostScript, by using an ordinary 
shape, which is created as part of the image, to define the 
region. In the present invention, the artist creates a shape 
representing the extent as part of the page image, and 
specifies a particular trigger color or gray scale for the 
shape. Thus, the artist could include a medium gray scale 
rectangle in the upper left-hand corner of the page, with 
the boundaries of the rectangle representing the extent 
which the artist has defined for the graphics state posi- 
tioned at that corner of the page. The medium gray scale 
will then represent the trigger color, and will be specified 
as the trigger for the region attribute in a job file 18 in the 
printer 12. 

[0027] | n addition, a second parameter in the job file 18 can be 
used to specify whether the rectangle should appear on 
the page, or whether it is being used only to define a 
graphics state extent. Thus, if the artist also wants the 
medium gray scale rectangle to appear on the printed 
page, this parameter enables the color to act as a trigger, 
yet not inhibit the artist's design. When the rectangle is 
interpreted during the method of this invention, the con- 
trol task will detect the trigger color and will save an "in- 
visible" boundary represented by the rectangular as part 



of the graphics state. 

[0028] As the PostScript attributes are defined, they are placed in 
a stack. When a new attribute is defined, it is added to the 
top of the stack. When an attribute is deleted, it is re- 
moved from the stack. The combination of all of the at- 
tributes located in the stack at any point during the exe- 
cution of the PostScript interpreter 14 constitutes the "cur- 
rent" graphics state for the page. 

[0029] when the interpreter reaches a print command, such as 
"SHOW" in PostScript, the command triggers the control 
task to interrupt the interpreter program. During this in- 
terruption, the control task interprets data in the 
PostScript file 11 and reserves a graphics state if the data 
is variable. Normally in a PostScript file, data which is to 
appear on the printed document is enclosed within paren- 
theses. Thus, the control task identifies data in the file 11 
by locating parentheses in the code. 

[0030] After the control task identifies the data, it interprets the 
data to determine whether it is static data, which is to be 
part of the page template, or variable data. To interpret 
the data, the control task first reads the data located in 
the parentheses and compares the data with a list of lit- 
eral data strings stored in the job file 18. The job file 18 



contains a list of data strings which are each associated 
with the name of a graphics state and its corresponding 
data field in a merge file 20. In the preferred embodiment, 
the graphics state name is the same as the field name in 
the merge file 20. The merge file 20 contains variable data 
arranged in records, with each record corresponding to a 
different page. Each record contains one or more data 
fields, which each correspond to separate variable data 
areas on the page. The list of data strings and associated 
graphics state names is entered in the job file 18 by the 
print operator prior to initiating the print job. If the data 
from the PostScript file 11 matches a data string in the job 
file 18, the control task replaces the data from the file 11 
with the graphics state name associated with the match- 
ing data string. In this manner, the control task trans- 
forms static data in the PostScript file into a variable data 
field, by substituting a graphics state field name for the 
static data in the file. 
[0031] | n a second embodiment, the graphics state name corre- 
sponding to the data area is defined directly within the 
PostScript file 11, by making the name part of the image 
that is created in the application program. In this embodi- 
ment, the name is enclosed within brackets in the file, 



such as "<< >>", to enable the control task to identify the 
data as defining a graphics state rather than being an or- 
dinary data string. Thus, to define the graphics state "AD- 
DRESS" within the PostScript file 11, the following would 
appear before a show command in the code: 
"(<<ADDRESS>>)". This second embodiment is advanta- 
geous in that it does not require the control task to com- 
pare the file data with a data list in the job file 18; how- 
ever, it does require coordinating the graphics state and 
field names between the merge file 20 and the application 
program. 

[0032] |f the control task determines that the data corresponds to 
a variable area, it reads the current contents of the graph- 
ics state stack to determine the attributes to be used for 
printing data in that area. In addition to the PostScript at- 
tributes specified in the stack, the graphics state can also 
include attributes which are specifically tailored to vari- 
able data printing. These additional attributes can either 
appear after the graphics state name inside a "show" 
command, if the graphics state is defined directly in the 
PostScript file, or can be specified in the job file 18 prior 
to execution of the print job. These additional attributes 
specify how the variable data is to be positioned within 



the graphics state. The following is a list of the variable 
data attributes which can be specified for a print job: 
Name: A label used to identify the data to which the 
graphics state applies. A single datum may be inserted 
into more than one graphics state so this attribute is not 
unique to a single state. 
[0033] Glyphs: A list of character glyphs, both attributes and im- 
ages, which are available for use in the graphics state, 
(e.g. an alphabet of 72 point Times-Roman bold italic 
characters). 

[0034] static Data: Data to be used in the event that variable data 

is not available. 
[0035] identification: A number used to uniquely identify a 

graphics state. 

[0036] justification: How to handle the text left to right - left 

border, right border, centered or justified. 
[0037] Alignment: How to place the text vertically in the graphics 

state. This could be top, bottom or centered. 
[0038] word Wrapping: Selects a word wrapping algorithm. 

[0039] Dynamic Registration: Information on how to determine 
the registration from one page to the next. 

[0040] Logic Mode: The manner in which the bitmap merge takes 
place. This is one of seven binary combination techniques. 



[0041] DP Procedure: A procedure (or program) used to manipu- 
late the variable data just before the graphics state is ap- 
plied. 

[0042] D ata Selection: Which portions of the variable data to use. 

[0043] Underline: Selects underlined text. 

[0044] when the control task is triggered to reserve a graphics 
state, the above listed attributes, if specified, are com- 
bined with the PostScript attributes from the stack, and 
reserved as a single graphics state under the name ob- 
tained from the PostScript file 11 or the job file 18 such as 
shown at 22. 

[0045] After the control task has compiled the attributes for the 
current graphics state, it may instruct PostScript to gener- 
ate a font cache 26 for the graphics state. The font cache 
26 consists of a character bit map for each of the al- 
phanumeric characters A-Z and 0-9 generated in the font 
specified in the graphics state. After PostScript has gener- 
ated all of the character bit maps, and placed the bit maps 
in the font cache 26, the font cache is linked to the 
graphics state 22, and reserved in the database. After the 
control task has reserved the current graphics state 22 
and the font cache 26 in the database, it resumes execu- 



tion of the PostScript interpreter 14 at the first line of 
code after the print or "SHOW" command, so that the print 
command is not executed. 
[0046] After the interpreter is resumed, it continues defining 
graphics state attributes for the page, until the control 
task detects another print or "SHOW" command. Upon de- 
tecting another print command, the control task again in- 
terrupts execution of the interpreter, and determines 
whether the data in the PostScript file 11 corresponds to a 
variable data area. If the data corresponds to a variable 
data area, the control task again substitutes a graphics 
state name from the job file 18 for the data in the 
PostScript file 11, and reads the graphics state attributes 
from the stack and job file. The control task also instructs 
PostScript to generate another font cache, if the attributes 
of the current graphics state differ from the attributes of 
previously reserved graphics states. The current graphics 
state and font cache are then linked, and reserved in the 
database under the second graphics state name from the 
job file 18, such as shown at 24. If the data does not cor- 
respond to a variable data area, the control task resumes 
execution of the interpreter at the print command, so that 
a bit map for the data can be generated and added to the 



template. 

[0047] At the final line of code, the template is complete, and in- 
corporates all of the static text and graphic data that is to 
appear on the printed document. At this point, the control 
task terminates the interpreter, and saves the template to 
the database such as shown at 28. In PostScript, the con- 
trol task is triggered to save the template by the "SHOW- 
PAGE" command. 

[0048] since the control task of the invention operates externally 
of the PostScript interpreter, the method of the present 
invention enables bit maps and graphics states to be gen- 
erated by the interpreter in a conventional manner. How- 
ever, rather than printing a completed page map at the 
end of the interpreter program, the method of this inven- 
tion reserves the page maps, character bit maps and 
graphics states generated by the interpreter, in order that 
they may be subsequently accessed and used to print 
multiple pages of variable data. 

[0049] After the interpreter has been terminated, the control task 
initiates the merge task 16. The merge task 16 interfaces 
between the merge file 20, which has been pre- 
programmed with items of variable data, and the database 
in which the templates, font caches and graphics states 



defined by the interpreter have been saved, in order to 
combine the variable data with a template on a single 
page map. The merge task 16 begins by accessing the 
merge file 20 to retrieve the name of the template for the 
page, and then retrieving the specified template from the 
database. In addition, the merge task 16 retrieves the 
names of the data fields and reserved graphics states 
which are associated with the selected template from the 
merge file 20. 

[0050] using the name corresponding to the first graphics state 
on the page, the merge task 16 accesses the merge file 20 
and retrieves the data stored under that field name in the 
first data record. In the representative merge file 20 
shown in Fig. 1, the field names are NAME and NUMBER. 

[0051] After the merge task 16 has read the data corresponding 
to the designated field name, it retrieves the graphics 
state which was reserved under the same name, as well as 
the character bit maps which are linked to that graphics 
state. The merge task 16 then generates a bit map of the 
data in accordance with the graphics state attributes. Af- 
ter the bit map is generated, it is merged into the tem- 
plate at the region corresponding to the graphics state, by 
writing the data bit map over the existing template bit 



map. 

[0052] | t w j|| b e apparent to those of ordinary skill in the art that 
it is within the scope of the invention to write the data bit 
map over a clean page as opposed to the template 
bitmap. For example, if the template contains no static 
bitmap data, then it would not be necessary to save an 
empty bitmap of the template in the database as de- 
scribed above. Thus, it is within the scope of the invention 
that the PostScript file 11 defines only variable data areas 
and does not define any static data areas. Such a 
PostScript file is illustrated in Fig. 1. 

[0053] After the data from the first field has been merged into 
the template, the merge task 16 reads the name corre- 
sponding to a second variable data area from the merge 
file 20, if a second variable area exists on the page. The 
merge task 16 then retrieves the graphics state and linked 
font cache having the same name as the second variable 
area. Next, using this name, the merge task 16 again ac- 
cesses the merge file 20, and reads the data from the field 
of the same name. The merge task 16 then generates a bit 
map for the data in accordance with the graphics state 
and font cache, and again merges the data bit map into 
the template 28. 



[0054] The merge task 16 continues the steps of identifying vari- 
able data areas for the template, retrieving graphics states 
and character bit maps corresponding to the variable ar- 
eas, accessing variable data from the merge file 20, and 
generating bit maps for the variable data, until bit maps 
have been generated and merged for all of the variable 
data to be included on the page. When a bit map has been 
generated for each variable data area, and merged with 
the template 28, the pagemap is output for printing as 
shown at 29. 

[0055] The merge task 16 then proceeds with printing a second 
page using the same template and graphics states, but a 
different variable data record in the merge file 20. To 
print the second page, the merge task 16 retrieves a 
"clean" template from the database. Next, the merge task 
16 again identifies the name of the first variable data area 
for that template and retrieves the graphics state of the 
same name. Then, the merge task 16 reads the data for 
that field from the second record of the merge file 20, and 
generates a bit map of the data using the retrieved graph- 
ics state attributes and character bit maps. Once the bit 
map is generated, the merge task 16 merges the bit map 
into the template by writing the bit map over the template 



at the location defined by the graphics state. 

[0056] The merge task 16 then continues processing in this 

manner until bit maps have been generated and merged 
into the template for all of the graphics states reserved for 
the page. After all of the bit maps for the second page 
have been merged into the template, the page is printed. 
The merge task 16 continues, repeating these steps for 
each record of data in the merge file 20, until all of the 
variable data records have been printed on a page. 

[0057] Figure 2 shows a variable data page printed in accordance 
with the method of this invention. On this page, the data 
fields 30 and 32 are static fields which are part of the 
page template. The data field 34 containing the name 
"William" is a variable data field. Different names such as 
Mark or Sam, from the merge file 20, are printed in this 
field on subsequent pages. The font, angle and color con- 
trast in which "William" is displayed are all aspects of the 
graphics state which were defined and stored during the 
steps of the present invention. Data field 36 which con- 
tains the number "00467727" is a second variable data 
area on the page. Again, the data displayed in this area 
varies on each page, depending upon the contents of the 
merge file 20. 



[0058] while the method described constitutes a preferred em- 
bodiment of the invention, it is to be understood that the 
present invention is not limited to this precise form, and 
that variations may be made without departing from the 
scope of the invention. 

[0059] what is claimed is: 



